home *** CD-ROM | disk | FTP | other *** search
/ Amiga Developer CD v2.1 / Amiga Developer CD v2.1.iso / DevInfo / Exec_and_PowerPC / FutureOS next >
Text File  |  1996-07-19  |  6KB  |  152 lines
  1.  
  2.     $Id: FutureOS 1.2 1996/07/20 09:24:38 heinz Exp $
  3.  
  4. Amiga technologies is committed to move towards a PowerPC Amiga
  5. fairly rapidly. This means that the OS will change in many
  6. respects on the PowerPC side of things. We don't want to move just
  7. towards "OS 3.1 on a PowerPC", we want a better and modern OS.
  8. Quite a few changes will happen not only to exec.library but also
  9. to other subsystems. Many things are so low level that you have to
  10. be careful about them. This means that struct ExecBase and low
  11. level HW stuff should be considered a black box as far as humanly
  12. possible. We will add restrictions and declare previously used
  13. practices that stop us from moving forward illegal for PPC code.
  14. For previously legal things that cannot be supported any longer, we
  15. will have new replacement functionality.
  16.  
  17. Specific restrictions and hints:
  18.  
  19.     - Do not use SysBase->ThisTask. DON'T! Use FindTask(NULL)
  20.       instead. On a PowerPC Amiga, you might regret using ThisTask.
  21.       While the OS 3.1 includes say "readable", as of January 1st,
  22.       1996, ThisTask is a private field.
  23.  
  24.     - Cache SysBase! Do not access $4 all the time if you can cache
  25.       that value! This will improve performance a lot!
  26.  
  27.     - Stay away from Disable() and Forbid(). STAY AWAY FROM THEM!
  28.       The semantics of Forbid() may be restricted to certain
  29.       allowed uses. Use semaphores to protect shared data.
  30.       Use of Forbid() "to speed up things" only demonstrates
  31.       incompetence. Don't ever use inline macros for these
  32.       functions and fix code that does.
  33.  
  34.     - Use semaphores to synchronize data access. Do not rely on
  35.       "atomic" CPU instructions, task priorities or Forbid().
  36.       Use signals and message replies for communication
  37.       by interrupt code. Don't depend on current behaviour of the
  38.       scheduler.
  39.  
  40.     - Don't try to fiddle with the Lists in ExecBase. They might
  41.       disappear. A new OS will provide access functions for really
  42.       important stuff. See the warning about Forbid().
  43.  
  44.     - Stay away from low level functions like trap or exception
  45.       handling functions.
  46.  
  47.     - Stay away especially from these functions:
  48.  
  49.         exec.library/AllocAbs
  50.         exec.library/AllocTrap
  51.         exec.library/Disable
  52.         exec.library/Enable
  53.         exec.library/Forbid
  54.         exec.library/FreeTrap
  55.         exec.library/GetCC
  56.         exec.library/ObtainQuickVector
  57.         exec.library/OldOpenLibrary
  58.         exec.library/Permit
  59.         exec.library/SetExcept
  60.         exec.library/SetFunction
  61.         exec.library/SetIntVector
  62.         exec.library/SetSR
  63.         exec.library/SetTaskPri
  64.         exec.library/SuperState
  65.         exec.library/Supervisor
  66.         exec.library/UserState
  67.  
  68.       They may change, become completely or partly obsolete and
  69.       unusable. This does not mean that you don't have to be
  70.       careful about use of any other functions. If you feel that
  71.       something might be a hack, better don't do it!
  72.  
  73.     - Note not only for SetTaskPri(): It is not legal to modify
  74.       tasks that you do not handle and own.
  75.  
  76.     - OldOpenLibrary() will finally end in an Alert(). Yeah!
  77.  
  78.     - Expect interrupt handling to change in many ways. If you can,
  79.       don't do interrupt stuff. Stay at the task/process level.
  80.  
  81.     - You could theoretically still access these fields
  82.  
  83.         AttnFlags   (which will be pretty useless on a PowerPC and
  84.                      replaced with a query function)
  85.  
  86.         VBlankFrequency (which has always been a tricky value)
  87.  
  88.         PowerSupplyFrequence    (which is no longer accurate even
  89.                                  on current hardware)
  90.  
  91.       if they were still there in a future OS, but obviously we
  92.       will set up access function for the necessary things.
  93.  
  94.     - If there is an OS function to do things or access structures,
  95.       use it. If there isn't, you should take this as indicator
  96.       that you should not do those things at the moment.
  97.  
  98.     - The HW that you know will disappear, too. No more hacking
  99.       into OCS/ECS/AGA registers. Use graphics.library. No more
  100.       hacking into CIA's. Use timer.device, parallel.device,
  101.       serial.device.
  102.  
  103.     - If you can feel that something might be of questionable
  104.       value, stability, or portability even before you did it, then
  105.       don't do it.
  106.  
  107.     - The OS can not and could not be shut down and revived again.
  108.       Don't even try it. You will die, lose all the functionality
  109.       and experience all the nasty things hidden by the OS.
  110.  
  111.     - Banging the HW usually only shows incompetence.
  112.  
  113.     - A different CPU will obviously use a different assembly
  114.       language with different instructions and restrictions. Don't
  115.       expect highly CPU dependend things like calling conventions
  116.       and LVO tables to remain the same. Another reason to stay
  117.       away from assembler if you want to stay portable.
  118.  
  119.     - As mentioned above there won't be something like an "atomic
  120.       instruction" anymore. You must use semaphores or appropriate
  121.       access functions to modify fields where a simple bit change
  122.       with one instruction used to be sufficient on a 680x0 based
  123.       machine. The OS will change appropriately to be
  124.       multiprocessing compatible. This is important, so we mention
  125.       it again.
  126.  
  127.     - From the notes above you can see that there may or may not be
  128.       a very tightly integrated 68K emulation on a PowerPC machine.
  129.       We won't trade PowerPC performance for 68K emulation. If we
  130.       did, we could go on building 68K machines exclusively. The
  131.       future emphasis is on PowerPC obviously, not on 68K. An
  132.       emulation will most likely not give you what native code
  133.       can do. Don't expect switching on the fly between arbitrary
  134.       pieces of code for different CPU types just whenever you feel
  135.       like it.
  136.  
  137.     - Stay modular, clean, and in a high level language for better
  138.       compatibility and portability.
  139.  
  140. Realize what this means? On a PowerPC Amiga, ExecBase and a lot
  141. more in the OS as you know it will disappear and change. Just like
  142. IntuitionBase did in 1991. To quote a really good comment:
  143.  
  144.     /* I told you this was private.
  145.      * The data beyond this point has changed, is changing, and
  146.      * will continue to change.
  147.      */
  148.  
  149. Heinz Wrobel
  150. <heinz@amiga.de>
  151.  
  152.